Jenkins Kata 6: Deploying Containers (Steps 1–3)

Learn about adding a build pipeline, defining and configuring a development, and adding a pipeline view, as well as about quality assurance and production environment deployment jobs.

The final step of this CI pipeline is to deploy the images as containers. This kata will demonstrate how to configure Jenkins to deploy to multiple environments. Environments are isolated sets of infrastructure to which software is deployed.

Software is typically delivered in a series of phases to a set of separate environments. Each environment is used for a different set of actions in the delivery lifecycle. The names of the environments differ somewhat between organizations. Here’s a common set of environments and their functions:

Development (Dev): This is typically the first environment where software is deployed after being integrated. This environment is constantly changing as new code is contributed and may be in a nonfunctional state at any given time. Developers use this environment to conduct basic functional testing, sometimes referred to as smoke testing.

Test: Test environments are commonly used for integration, performance, and functional testing. The test environment is also a break-fix environment, similar to Dev, and is generally not expected to be stable at all times.

Quality assurance (QA): The QA environment is typically expected to be available and functional at all times. Software deployed to this environment has been tested for essential functionality. QA environment activities include performance testing, security testing, and compliance testing.

User acceptance (UA): End users and management staff use the UA environment to validate that the software meets the requirements agreed upon between business users and IT staff. UA environments are also useful for training users on new features. Some organizations combine the QA and UA functions into a single environment.

Production (Prod): This is the live environment where end-users and/or customers interact with the software to conduct the business for which the software was designed. Some organizations split this environment into preproduction and production, providing one additional step before new software is made available to the user base.

This kata will complete the CI pipeline with a sequence of actions that will deploy the “web-storelist” application locally within the LVM. The web-storelist container will be deployed within the LVM to the environments listed above. The LVM has been set up to simulate the URLs that would typically be used. A real deployment job would deploy these containers to other servers in a data center or a cloud.

Step 1: Add the build pipeline plugin#

  • Click the Jenkins icon at the top left.
  • Click “Manage Jenkins.”
  • Click “Manage Plugins.”
Click “Manage Jenkins” and then “Manage Plugins”
Click “Manage Jenkins” and then “Manage Plugins”
  • Click the “Available plugins” tab.
  • Enter “build pipeline” into the filter field.
  • Check the box next to the “Build Pipeline” plugin.
  • Click “Install without restart” (and then wait for the install to complete).
  • Click “Go back to the top page.”
Select “Build Pipeline” plugin
Select “Build Pipeline” plugin
Plugin installed successsfully
Plugin installed successsfully

The Build Pipeline plugin provides a visual representation of a build pipeline. A build pipeline is simply a set of jobs that are configured to execute in a particular order. This kata will configure a set of jobs to do just that. We’ll create jobs that execute other jobs, deploying images as running containers to their respective environments.

Step 2: Define a dev environment deployment job#

  • Click “New Item.”
  • Enter “dev-deploy-storelist” in the item name field.
  • Select the “Freestyle” project.
  • Click “OK.”
Click “New Item”
Click “New Item”
Adding the name of the job and selecting the “Freestyle project”
Adding the name of the job and selecting the “Freestyle project”
  • Click the “Build Steps” tab.
  • Select “Add build step.”
  • Select “Execute shell.”
Adding the "Execute shell" build step
Adding the "Execute shell" build step
  • Enter (or copy and paste) the following into the “Command” field:
  • Click “Save.”
Adding the command in the “Command” field
Adding the command in the “Command” field

Executing this job runs a container named dev-storelist from the storelist image, assigning an IP address associated with the Dev environment. This effectively deploys to the Dev environment.

  • Switch to a terminal window.
  • List the running containers as follows:
Listing Docker containers

Step 3: Configure the Dev deployment job trigger#

  • Switch to the Jenkins tab.
  • Click the Jenkins icon at the top left.
  • Select the web-storelist job.
  • Click “Configure.”
Select "web-storelist" and click "Configure"
Select "web-storelist" and click "Configure"
  • Click the “Post-build Actions” tab.
  • Select “Build other projects.”
  • Enter “dev-deploy-storelist” in the “Projects to build” field.
  • Click “Save.”
Select “Build other projects” from the “post-build action” tab
Select “Build other projects” from the “post-build action” tab
Add “dev-deploy-storelist” in the “Projects to build” field
Add “dev-deploy-storelist” in the “Projects to build” field

CI constantly combines new code submissions, ensuring that they work together and don’t introduce errors or failures. CD is the automated deployment of tested code to an environment. This step configures the web-storelist job to execute the Dev deployment job each time the web-storelist job executes successfully.

The effect of this configuration is that the Dev environment is always running the most recent successful build of web-storelist. Developers, testers, and anyone who needs to work with the application in the Dev environment can do so using the latest code without waiting for a manual deployment.

This constant stream of new work deployed to the Dev environment enables velocity. Velocity is the rate at which work is completed, tested, and delivered. The faster and more frequently work is delivered, the more cost-effective the IT department is for the business it supports.

  • Switch to a terminal window.
  • Change to the web-storelist directory as follows:
cd /dk/web-storelist
  • Open storelist.htm with the text editor:
nano storelist.htm
  • Add a new item from the Main List to the Next Visit list.
  • Save the changes.
Adding a new item
  • Return to the terminal window.
  • Check the status of the repository.
  • Commit the change to the repository.
  • Push the commit to the Gogs server.
Commit and push the changes

Commands

Command / Parameter

Description

git status

This returns the current status of the local Git repository. This command shows that the storelist.htm file has been modified.

git commit

This creates a new commit in the local repository.

-a

This includes all the modified files in the commit.

-m

This adds a commit message.

“Added another item”

This is the commit message to assign to the commit.

git push

This pushes all the commits that haven't been pushed to a remote repository.

origin

This is the name of the remote repository. This is the Gogs server in this case.

master

This is the branch to push to the remote.

The storelist.htm file is edited and added to a commit to the local repository, and that commit is then pushed to the remote Git server. This is a typical sequence of events during development. Developers will do some work, create one or more commits, then push those commits to the remote. The configuration created to this point then executes a sequence of actions:

  1. Updating the main branch executes the Gogs webhook, causing Gogs to send a command to Jenkins.
  2. Jenkins responds by executing the web-storelist job, which runs the build of the storelist Docker image.
  3. The web-storelist job is configured to run the dev-deploy-storelist job, which deploys the new image by running a new container in the Dev environment.

This is CI and CD in action. One event, the push of new commits, triggers a series of automated events. If all goes well and the tests pass, the new code is immediately running in Dev.

  • Return to the Jenkins tab.
  • Click “Build History.”
Build History

The Jenkins Build History displays records of all the builds executed by Jenkins. Two new builds are displayed: one for web-storelist and another for dev-deploy-storelist. These builds were triggered by the push of the new commit to the Gogs server.

Jenkins Kata 5: Docker Container Build Step

Jenkins Kata 6: Deploying Containers (Step 4–6)